Implement light-client spec tests #4908
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Performance Report✔️ no performance regression detected Full benchmark results
|
dadepo
reviewed
Dec 15, 2022
dadepo
reviewed
Dec 15, 2022
| /** From https://notes.ethereum.org/@vbuterin/extended_light_client_protocol#Optimistic-head-determining-function */ | ||
| const SAFETY_THRESHOLD_FACTOR = 2; | ||
|
|
||
| export function sumBits(bits: BitArray): number { |
There was a problem hiding this comment.
This function is defined in 3 different places across the code base now. Here, in the beacon node package, and in the light client src. Might be good to have it only in the util package.
There was a problem hiding this comment.
Such a tinny function, which is just an alias for readability on the SSZ method. I think it's better to have 2 extra lines than a random function in the utils package.
dadepo
reviewed
Dec 15, 2022
| // If update is not finalized finalizedHeaderSlot does not matter (see is_better_update), so setting | ||
| // to zero to set it some number. | ||
| finalizedHeaderSlot: attestedData.isFinalized | ||
| ? computeStartSlotAtEpoch(attestedData.finalizedCheckpoint.epoch) |
There was a problem hiding this comment.
is it safe to assume the finalised header slot will always be the first slot at the epoch?
There was a problem hiding this comment.
In this very specific case, IMO yes. That finalizedHeaderSlot is used only to break ties in the is_better_update function. If the finalized checkpoint advances is extremely unlikely that the referenced block's slot does not increase. Even if it didn't the consequence is just persisting a slightly different update under some circumstances
dadepo
reviewed
Dec 15, 2022
| } | ||
|
|
||
| // Sanity check that slots are in correct order | ||
| if (update.signatureSlot <= update.attestedHeader.slot) { |
There was a problem hiding this comment.
The spec also include the current_slot >= update.signature_slot assertion. Is it a conscious decision to not include that?
There was a problem hiding this comment.
Yes, to remove the dependency on the clock from this function. That check is done on the caller of this function
dadepo
reviewed
Dec 16, 2022
| }; | ||
| const lightClient = new LightclientSpec(config, lightClientOpts, testcase.bootstrap); | ||
|
|
||
| // fromHex(testcase.meta.trusted_block_root) |
dadepo
reviewed
Dec 16, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Implement
light-clientspec tests from https://github.com/ethereum/consensus-specs/tree/dev/tests/formats/light_clientDescription
single_merkle_proofsync: Re-used new code in actual light-client classupdate_ranking